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NAVTRAEQU I PCEN  IH-325 
SECTION  I 
GENERAL  OVERVIEW 


Analysis  is  a  natural  human  activity,  a  more  or  leso  logical  form  of 
problem-solving  cehavior.  It  occurs  when  the  appropriate  response  to  a  problem 
is  uncertain,  i.e.,  when  information  is  required  to  make  a  choice  among  alterna¬ 
tives.  In  contrast,  a  reflex  is  a  non-analytical  process.  It  is  automatic  and 
certain.  No  decision  among  alternatives  is  required.  If  your  hand  touched  a 
red-hot  surface,  it  would  be  withdrawn  without  equivocation.  However,  if  your 
key  broke  in  the  lock  of  your  car  door,  you  woulc  have  a  problem  to  which  you 
might  make  many  responses  (some,  perhaps,  inappropriately  reflexive). 

The  analytical  character  of  our  reasoning  in  problematic  situations  usually 
is  not  explicit.  The  various  priorities,  assumptions,  and  bits  of  information 
that  underlie  most  of  our  decisions  thus  are  not  often  open  to  evaluation.  This 
intuitive  approach  serves  us  remarkably  well  except  when  (a)  the  cost  or  risx 
associated  with  decisions  is  high,  and  (b)  the  considerations  on  which  decisions 
are  based  must  be  communicated  effectively  to  others.  These  are  precisely  tie 
conditions  that  nave  motivated  efforts  to  objectify  the  analysis  process.  Tne 
following  represents  one  attempt  in  this  direction  -  an  approach  which  stresses 
the  central  role  of  information  in  analysis. 

At  the  core  of  analysis  we  find  a  fundamental  process  which  may  be  concep¬ 
tualized  as  a  decision  loop  such  as  that  in  Figure  1.  As  the  diagram  shows,  the 
existence  of  a  problem  creates  a  need  for  information.  Once  the  needed  informa¬ 
tion  has  been  gathered,  a  decision  is  made  among  alternative  courses  of  action 
directed  at  solution  of  the  problem.  When  the  decision  is  acted  upon,  a  new 
problem  emerges  or  the  old  problem  may  be  redefined  in  greater  detail.  The 
cycle  is  then  repeated  at  a  finer  level  of  specificity.  Each  repetition  of  the 
loop  improves  resolution  of  the  problem  and  the  action  needed  to  solve  it.  This 
iterative  process  terminates  when  further  analysis  of  the  problem  fails  to  yield 
any  significant  new  information,  or  when  further  action  is  prohibited  by  con¬ 
straints  such  as  time  and  cost. 

The  element. ry  decision  loop  may  be  elaborated  to  encompass  the  activities 
tnat  characterize  the  front-end  analysis  process  in  large  scale  system  develop¬ 
ment  projects.  As  indicated  ii.  the  analysis  loop  illustrated  in  Figure  2, 
information  assumes  a  role  central  to  the  whole  process.  The  process  itself  is 
usually  initiated  by  an  operational  requirement  (OR)  which  arises  in  response  to 
some  anticipated  or  existing  need  in  the  fleet,  “he  degree  of  detail  specified 
in  the  GR  reflects  the  level  of  information  available  at  the  time  of  its  origi¬ 
nal  formulation.  Less  information  is  initially  available  in  the  case  of  emerg¬ 
ing  systems  than  in  the  case  of  existing  systems,  and  the  early  system  require¬ 
ments  (which  are  developed  from  the  OR)  for  emerging  systems  are  correspondingly 
less  detailed.  Development  of  emerging  systems  thus  presumes  an  increase  in  the 
specificity  of  system  requirements  based  on  an  expansion  of  the  supporting 
info rmation. 

Each  cycle  .nrough  the  loop  enlarges  the  information  data  bank  and  results 
in  a  furtner  refinement  of  the  system  requirements.  The  system  emerges  as  the 
requirements  develop. 
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Figure  1.  Decision  Loop. 
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Figure  2.  Front-End  Analysis  Loop  for 

Large  Scale  System  Development 
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At  each  level  of  refinement,  decisions  are  made  among  alternative  concep¬ 
tualizations  and  action  strategies.  This  requires  information  -  both  the  infor¬ 
mation  necessary  for  formulation  of  alternatives,  and  that  necessary  for  evalua¬ 
tion  and  selection  of  the  "best"  from  among  them.  The  major  source  of  this 
information  is  some  form  of  problem  analysis,  a  procedure  for  collecting  and 
assimilating  the  data  that  characterize  a  system  at  its  current  level  of  devel¬ 
opment  and  provide  tne  foundation  for  an  advance  of  the  system  to  its  next 
level . 

The  alternatives  generated  by  front-end  analysis  at  one  level  (cycle)  in 
the  emergence  of  a  system  generally  will  not  be  the  same  as  those  generated  in 
later  cycles.  As  the  data  base  of  information  builds  up  through  repeated  cycles 
around  the  loop,  the  alternative  conceptualizations  and  strategies  become  pro¬ 
gressively  more  functional  and  detailed,  and  the  scenarios  for  action  inherent 
in  them  become  more  realistic. 

In  addition  to  the  system-specific  data  needed  to  identify  alternatives, 
problem  analysis  also  provides  clarification  of  objectives  and  establishes  an 
accurate  picture  of  resources  and  constraints.  It  is  in  terms  of  these  data 
that  the  various  alternatives  are  evaluated.  Given  the  required  and  available 
resources,  and  the  constraints  on  further  development,  then  it  is  possible  to 
establish  the  projected  costs,  potential  effectiveness,  and  likely  risks  en¬ 
tailed  by  each  al ternati ve.  Essentially,  it  is  this  information  that  consti¬ 
tutes  evaluation.  And,  like  the  information  generated  at  the  problem  analysis 
stage  of  the  loop,  the  evaluative  information  becomes  more  refined  and  specific 
on  each  successive  cycle  around  the  loop. 

Output  from  the  evaluation  stage  of  front-end  analysis  provides  the  primary 
information  base  needed  to  select  the  optimal  alternative.  However,  several 
additional  kinds  of  information  may  also  come  into  play  during  selection,  e.g., 
past  experience  with  similar  alternatives;  organizational  policies,  priorities, 
and  long-range  goals;  technological  state-of-the-art  and  capacity  for  innovative 
development;  etc.  These  factors  combine  with  resources  and  constraints  data  to 
form  the  criteria  that  are  used  to  select  the  "best"  from  among  the  alternatives. 
The  validity  of  the  selection  criteria  improves  as  the  information  on  which  they 
are  based  increases,  and  so  the  alternative  selected  on  each  cycle  through  the 
loop  approximates  more  and  more  closely  an  optimal  plan  for  action. 

The  steps  involved  in  this  process  may  be  illustrated  in  terms  of  a  flow 
diagram  such  as  the  one  in  Figure  3.  Note  that,  once  the  "best"  alternative  has 
been  selected,  a  decision  point  is  reached.  If  the  specificity  of  the  alterna¬ 
tive  is  not  adequate  to  proceed  with  an  action  (system  development,  design, 
etc.),  a  new  system  requirement  is  defined  and  analysis  is  repeated.  This 
iterative  approach  to  front-end  analysis  results  in  a  step-wise  increase  in  the 
specificity  of  system  requirements  and  a  corresponding  advance  in  the  state  of 
the  system,  as  illustrated  in  Figure  4. 
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REQUIREMENTS  STATE  OF  THE  SYSTEM 


NEEDS  -  OPERATIONS  PROFILE 

!  GOALS  - - -  PARAMETERS  CONFIGURATION 

I  OBJECTIVES  -  FUNCTIONS  SPECIFICATION 

!  DESIGN  -  COMPONENTS  SYNTHESIS 

j  DEVELOPMENT  -  SYSTEM  PRODUCTION 

'  IMPLEMENTATION  -  SYSTEM  DEPLOYMENT 

{EVALUATION  -  SYSTEM  TESTING 


.  .  u  inLwn  i  i  yn  - j  ij  i  lh  i  . _ it  i  mu  > 

y  y 


Figure  4.  Levels  of  System  Emergence. 


System  requirements  formulated  in  terms  of  needs  are  less  specific,  based 
on  less  information,  than  tnose  generated  from  goals  statements.  Likewise,  if 
sufficient  information  is  available  to  stipulate  concrete  objectives,  the  re¬ 
sulting  system  requirements  will  be  more  specific  than  if  they  were  formulated 
in  terms  of  more  general  goals  statements.  The  point  of  this  is  that,  as  infor¬ 
mation  regarding  our  needs,  goals,  and  objectives  increases,  our  view  of  what 
the  system  should  accomplish  becomes  more  definitive  and  sharply  focused.  The 
evolution  of  a  system  from  a  general  profile  of  its  desired  operations  to  its 
ultimate  deployment  follows  a  parallel  course  of  step-wise  increments  in  speci¬ 
ficity. 

As  knowledge  of  system  requirements  increases,  tne  state  of  the  system  may 
be  advanced.  The  alternatives  generated  at  each  level  of  analysis  become  more 
detailed,  are  based  on  more  information,  and  permit  a  more  definitive  descrip¬ 
tion  of  system  parameters  and  functions.  This  is  a  straight-line  evolution  of 
an  emerging  system.  It  appears  to  be  equally  characteristic  of  conceptual, 
organizational,  hardware,  and  training  systems.  It  also  applies  to  existing 
systems  implemented  at  some  less-than-ideal  stage  of  development. 

Can  this  straight-line  process  be  short-circuitec?  If  so,  there  would  be  a 
considerable  savings  in  time  and  cost. 

As  we  have  seen,  the  key  factor  in  the  evolution  of  systems  is  information. 
Indeed,  it  might  De  t.rgued  that  it  is  the  procurement  and  management  of  infor¬ 
mation  that  constitutes  one  of  the  primary  objectives  of  front-end  analysis. 

The  empnasis  here  is  on  the  availability  of  information  since  this  offers  the 
most  likely  avenue  for  short-circuiting  the  long-term  straignt-1 ine  process  of 
system  development.  Essentially,  a  method  is  needed  for  maximizing  the  utility 
of  the  information  t-at  is  available  at  the  time  an  operational  requirement 
arises.  This  presupposes  a  system  for  categorizing,  storing,  and  retrieving 
information  -  a  system  to  which  perhaps,  each  of  the  armed  services  could  con¬ 
tribute,  and  from  wtrch  each  could  draw  the  information  it  needed.  Such  a 
scheme  is  illustratec  in  Figure  5. 

Tne  generic  information  management  system  outlined  in  the  diagram  is  not 
the  usual  "librarian's”  model  which  takes  in,  files,  end  provides  selective 
access  to  stored  information.  Instead,  this  categorical  process  is  merely  the 
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Figure  5.  Generic  Information  Management  System. 
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first  important  step  in  the  generic  model.  The  second  step  is  a  commonality 
analysis  that  is  carried  out  on  all  systems  of  a  given  type  that  are  available 
in  the  information  pool.  The  purpose  of  a  commonality  analysis  is,  for  any 
given  type  of  system,  to  establish  the  generalized  requirements  that  apply  to 
all  instances  of  that  type  of  system.  For  example,  we  may  have  five  different 
systems  designed  to  achieve  the  same  kinds  of  mission  objectives.  Obviously, 
these  five  systems  -  though  different  -  must  have  some  things  in  common.  It  may 
be  that  the  general  operations  of  these  systems  share  certain  key  characteris¬ 
tics  that  are  critical  to  mission  accomplishment.  It  may  turn  out  that  certain 
major  parameters  are  present  in  each  system  as  well  as  a  few  primary  functions. 
The  main  differences  may  be  in  the  component  subsystems  that  make  up  the  hard¬ 
ware  of  each  system.  The  overall  picture  which  would  emerge  from  this  conmon- 
ality  analysis  would  tell  us  which  system  characteristics  have  been  found  to  be 
essential,  invariant,  to  the  accomplishment  of  certain  mission  objectives,  and 
which  characteristics  may  be  altered.  When  this  data  is  combined  with  perfor¬ 
mance  and  constraint  data,  it  is  possible  to  evaluate  both  the  invariant  and 
variant  system  characteristics  in  terms  of  their  real  contributions  to  mission 
achievement. 

Such  commonality  analyses  produce  generic  data  -  data  that  is  descriptive 
of  system  types  rather  than  individual  systems.  This  generic  data  would  be 
stored  (in  addition  to  system-specific  data)  and  made  available  for  selective 
access  in  the  model  proposed  here.  In  short,  a  generic  data  base  would  be 
estabi i shed. 

This  process  is  illustrated  in  the  diagram  shown  in  Figure  6.  Suppose  a 
need  arises  for  a  new  system  and  that  time  and/or  resource  constraints  will  not 
permit  the  straight-; ine  evolution  of  the  information  base  necessary  to  specify 
system  requirements.  The  generic  model  offers  a  way  around  these  constraints. 
The  model  says  to  go  to  the  information  pool  and  pull  out  existing  data  on 
systems  that  satisfy  needs  similar  to  the  one  we  are  now  facing  and  then  perform 
a  commonality  analysis.  From  the  resulting  generic  data  base,  a  set  of  general¬ 
ized  requirements  can  be  determined  that  will  serve  as  the  "best  estimate"  o,'  a 
system  that  will  meet  the  new  need.  Furthermore,  the  generic  data  generated  in 
the  process  can  be  stored  and  used  in  future  system  analyses.  Even  if  future 
analyses  are  not  constrained  by  either  time  or  costs,  the  generic  acta  base 
constitutes  a  superior  information  process,  one  which  does  not  force  js  to 
e'tner  start  from  scotch,  or  work  with  a  disorganized  plethora  of  r..w  data, 

-  ach  time  the  need  for  a  new  approach  to  an  old  problem,  or  a  unique  approach  to 
an  enti'ely  new  problem,  arises.  In  short,  the  generic  model  of  information 
management  permits  u-.  maximum  utilization  of  existing  information  and  thereby 
provides  us  with  a  more  accelerated  and  less  costly  approach  to  the  analysis  of 
systems.  In  light  o*'  this,  we  can  now  alter  our  analysis  loop  to  reflect  this 
generic  source  of  information  as  shown  in  Figure  7. 

The  tnesis  here  is  that  the  generic  approach  to  information  management  has 
me  potential  of  being  our  most  viable  tool  for  by-passing  the  long-term  often 
expensive  approach  to  front-end  analysis.  Our  "looks"  into  the  future  are 
essentially  estimates  derived  from  information  obtained  in  the  past.  There 
appears  to  be  no  way  known  to  science  or  technology  for  getting  around  this. 
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Figure  7.  Generic  Data-Based  Front-End 
Analysis  Loop. 
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Since  our  best  estimate  of  the  future  has  to  be  gleaned  from  the  past,  we  should 
proceed  to  establish  a  rational  methodology  which  will  optimize  the  usefulness 
of  the  information  now  available  to  us.  Otherwise  it  will  remain  fragmented  in 
isolated  bits,  will  tend  to  be  duplicated  needlessly,  and  will  not  be  general¬ 
ized  in  application  to  future  needs  and  systems. 
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SECTION  II 

STRAIGHT-LINE  FRONT-END  ANALYSIS 


Any  analysis  is  predicated  upon  the  availability  of  information,  whether  it 
no  qualitative  or  quantitative.  However,  the  mere  availability  of  information 
Coes  not  assure  that  any  useful  gain  will  be  realized.  In  fact,  the  utilization 
of  high  density  information  in  the  solution  of  complex  problems  may  be  impeded 
by  the  absence  of  an  appropriate  strategy  for  analytically  managing  information. 
Ideally,  such  a  strategy  would  provide  a  mechanism  for  integrating  factual  data, 
system  objectives,  management  and  budget  priorities,  and  major  sources  of  uncer¬ 
tainty.  It  would  also  identify  decision  points  in  the  analytic  process  and 
indicate  the  nature  of  the  information  needed  at  each  point. 

~ne  approach  to  front-end  analysis  described  in  this  section  is  an  attempt 
to  make  explicit  the  various  steps,  logic,  and  items  of  information  currently 
regarded  as  being  essential  to  evaluative  and  developmental  planning  at  the 
Naval  Training  Equipment  Center.  The  model  to  be  described  here  is  diagrammati- 
cally  presented  in  Figure  3.  Although  costs  and  time  constraints  may  require  a 
more  abbreviated  analysis,  i.e.,  the  analysis  must  be  short-circuited  at  some 
point  in  she  process,  an  overall  view  of  the  entire  process  may  aid  in  minimiz¬ 
ing  losses  in  analytic  power  due  to  inadvertant  elimination  of  essential  steps. 
Optimal  strategies  for  short-circuiting  the  straight-line  analysis  process 
presented  here  will  oe  described  in  the  next  section  under  the  heading  "Generic 
Information  in  Front-end  Analysis:  Training  Systems". 

Tne  stimulus  fcr  a  front-end  analysis  at  the  Naval  Training  Equipment 
Center  can  be  an  operational  requirement  (OR)  generated  by  the  Chief  of  Naval 
Operations  (CNO).  An  OR  may  be  produced  in  response  to  a  problem  within  an 
existing  fleet  system  or  by  the  emergence  of  a  new  threat  for  which  a  counter 
capability  must  be  developed. 

The  point  of  interest  here  is  that  the  OR  serves  as  the  basis  for  justify¬ 
ing  tne  funding  necessary  to  carry  out  front-end  analysis.  Insofar  as  the 
analyst  is  concerned,  the  operational  requirement  stipulates  the  needs  of  the 
fleet  and  the  time-cost  limitations  within  which  he  must  work.  It  is  within 
tnis  context  that  tne  analyst  must  frame  the  character  of  the  process  that 
ultimately  will  result  in  cost-effective  alternatives  from  among  which  the 
"best"  may  be  selected.  It  should  be  pointed  out  that  the  word  "requirement", 
as  used  in  the  preceding  section,  is  not  synonymous  with  "operational  require¬ 
ment".  System  requirements,  as  opposed  to  the  OR,  refer  to  needs,  goals,  or 
objectives  peculiar  to  the  system  called  for  by  the  OR.  Successive  iterations 
of  front-end  analysis  as  described  in  the  first  section  of  this  report  may  be 
largely  responsible  for  delineating  and  developing  these  requirements  for  emerg¬ 
ing  systems,  and  refining  or  re-defining  these  requirements  for  existing  systems 
in  need  of  additions,  expansions,  or  revisions.  As  indicated  in  Figure  4,  -the 
specificity  of  system  requirements  increases  as  the  state  of  the  system  advances. 
Consequently,  the  requirements  for  existing  systems  are  usually  available  in  a 
more  detailed  form  than  those  for  emerging  systems.  The  significance  of  this 
for  the  analyst  is  that  requirements  specificity  largely  determines  the  degree 
of  fineness  with  which  alternatives  may  be  specified  and  the  accuracy  with  which 
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alternatives  may  be  evaluated.  Determination  of  system  requirements  is,  there¬ 
fore,  of  paramount  importance  to  the  analyst  and  this  is  most  appropriately 
accomplished  through  a  problem  analysis. 

Although  time-cost  constraints  may  prohibit  a  full-scale  problem  analysis 
such  as  that  described  by  Funaro  and  Mulligan  (1979)1,  there  are  at  least  three 
categories  of  information  that  the  analyst  requires  in  order  to  successfully 
carry  out  a  straight-line  front-end  analysis.  These  categories  are  (1)  system 
requirements,  (2)  system  performance,  and  (3)  system  resources  and  constraints. 
Documentation  in  each  of  these  categories  is  normally  contained  in  the  problem 
analysis  report.  If  such  documentation  is  not  available,  and  cannot  be  obtained 
due  to  constraints,  the  validity  of  the  front-end  analysis  may  be  severely 
impaired.  In  such  an  instance,  the  analyst  has  little  real  data  on  which  to 
base  his  evaluation  other  than  the  collective  experience  of  those  familiar  with 
similar  systems  and  his  own  educated  speculations.  This  is  one  point  at  which 
the  availability  of  a  generic  data  base,  as  described  in  the  next  section,  could 
contribute  significantly  to  the  validity  of  a  front-end  analysis.  A  similar 
problem  may  exist  in  the  case  of  an  evolving  system  for  which  system  requirements, 
performance,  resources,  and  constraints  are  only  generally  specified.  It 
should  be  evident,  therefore,  that  the  starting  point  for  a  straight-line 
front-end  analysis  is  the  documentation  contained  in  the  problem  analysis 
report. 

Initially,  as  illustrated  in  Figure  3,  the  analyst  is  faced  with  a  compari¬ 
son  of  operational  requi rements ,  system  objectives  (or  system  requirements),  and 
system  performance.  Several  important  questions  arise  as  a  result  of  this 
comparison.  For  example,  are  system  objectives  consistent  with  operational 
requirements?  Laying  aside  the  problem  of  operational  requirements  validity, 
which  is  a  question  the  analyst  should  consider  also,  the  answer  to  the  fore¬ 
going  question  may  be  either  "yes",  "no",  or  "indeterminate".  In  case  the 
answer  is  "yes",  then  the  analyst  has  a  strong  incication  that  the  system  objec¬ 
tives  at  least  specify  the  direction  in  which  system  performance  should  be  aimec 
and  resources  concentrated.  In  case  the  answer  is  "no",  then  further  analyses 
probably  would  net  be  productive  until  the  reasons  for  the  discrepancy  have  jeer 
discovered  and  the  inconsistency  resolved.  In  case  the  answer  is  " indeterminate" , 
further  explication  of  the  OR  probably  would  be  necessary. 

A  second  question  inherent  in  the  comparison  is,  are  resources  adequate  to 
meet  system  opjectives?  Obviously,  if  the  answer  to  this  question  is  "no",  the 
analyst  is  faced  with  a  dilemma  which  must  be  resolved  before  proceeding  further 
with  the  analysis.  One  option  might  be  to  scale  down  the  system  objectives  to 
the  limit  permitted  by  the  OR.  A  second  option  might  involve  the  incorporation 
of  new  technological  developments,  more  streamlined  management  systems,  or  more 
efficient  utilization  of  existing  manpower  and  physical  resources.  Similar 
reasoning  would  apply  to  the  limitations  that  constraints  exert  on  the  realiz¬ 
ability  of  system  objectives. 


*J.  F.  Funaro  end  B.  E.  Mulligan  (July,  1979)  "Problem  Analysis  and  The 
Program  Master  Plan:  Key  Elements  in  the  Instruction  System  Development 
Process",  NAVTRAEQUIPCEN  Report  No.  IH-314. 
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A  third  question  that  derives  from  the  comparison,  and  perhaps  the  most 
interesting  one  in  the  case  of  existing  systems,  asks  if  system  performance 
meets  system  objectives.  Of  course,  this  question  would  apply  only  to  those 
areas  of  system  performance  for  which  objectives  were  available.  However,  if 
there  are  pertinent  areas  in  which  system  performance  has  been  documented,  but 
for  which  there  are  no  objectives,  the  analyst  might  well  develop  the  needed 
objectives,  making  sure  that  they  are  consistent  with  the  OR  and  that  they  will 
contribute  to  the  evaluation  of  alternatives  to  be  developed  later  in  the  analy¬ 
sis  process.  There  are  a  number  of  areas  of  system  performance  that  may,  or  may 
not,  be  pertinent  to  any  particular  system.  Among  the  most  frequently  encountered 
areas  of  performance  are  those  listed  below. 

1.  Productivity:  Output  or  output  per  manhour  (e.g.,  student  throughput). 

2.  Reliability:  Average  rate  of  failure  (e.g.,  malfunctions)  per  operating 
period . 

3.  Maintainability:  Number  of  manhours  to  perform  repairs,  system  inspec¬ 
tions,  etc. 

4.  Validity:  Correlation  between  system  and  post-system  parameters 
(e.g.,  fidelity  of  simulation,  transfer  of  training,  entry  versus  output  skill 
levels) . 

5.  Safety:  Number  of  accidents,  hazards,  etc. 

6.  Accuracy:  Frequency  of  system  errors. 

7.  Acceptance:  Attitudes,  morale,  etc.,  of  system  personnel  (e.g.,  manage¬ 
ment,  instructors,  etc.)  and  system  users  (e.g.,  trainees,  product  users  in  the 
fleet) . 

8.  Ecological  Impacts:  Energy  conservation,  environmental  effects, 
public  reactions,  etc. 

9.  Effectiveness:  Any  of  the  above  evaluated  relative  to  system  require¬ 
ments,  standards,  specifications,  etc. 

10.  Efficiency:  Resources  required  (expended)  be  achieve  system  outputs 
such  as  manpower  (e.g.,  student/instructor  ratio),  facilities,  equipment,  sup¬ 
plies  (training  "flights'Vgallons  fuel),  and  time  (training  objectives/unit 
instruction  time). 

The  process  of  -^solving  questions  raised  by  comparisons  of  system  require¬ 
ments,  objectives,  performance,  resources,  and  constraints  provides  the  analyst 
with  an  introduction  to  the  creative  and  complex  task  of  formulating  alternative 
plans  to  meet  the  objectives  of  the  system. 

Alternatives  provide  decision  makers  with  choices.  The  potential  gain  to 
be  realized  from  the  availability  of  choices,  however,  is  clearly  limited  by  the 
quality  of  alternatives  from  among  which  the  choices  are  to  be  made,  and  the 
di st ingui shabi 1 i ty  of  alternatives  powerfully  influences  the  certainty  with 
which  the  decision  maker  may  choose. 
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Quality  and  distinguishabil ity  of  alternatives  are  thus  two  important  goals 
towards  which  the  analyst  should  strive.  The  achievabil ity  of  these  goals  is 
largely  dependent  upon  the  adequacy  of  the  problem  analysis  data  since  this  is 
the  most  representative  information  on  the  state  of  the  system  available  to  the 
analyst.  However,  the  analyst's  experience,  knowledge  of  similar  systems,  and 
analytic  abilities  are  key  ingredients  in  the  formulation  of  viable  alternatives 
The  analyst's  willingness  to  consult  with,  and  his  openness  to  the  opinions  of, 
decision  makers  and  experts  in  relevant  fields  are  also  contributing  factors  at 
this  stage  in  front-end  analysis. 

There  appears  to  be  no  known  procedural ization  of  the  creative  activities 
involved  in  generating  alternative  action  plans,  any  more  than  there  are  formu¬ 
lae  for  producing  works  of  art.  However,  the  analyst  may  find  it  useful  to 
begin  with  the  formulation  of  an  "ideal"  alternative  plan.  To  do  this  the 
analyst  pretends  that  he  has  limitless  resources  and  no  constraints.  He  is  then 
free  to  ask  himself,  "Given  the  current  state  of  technology,  what  are  the  charac 
teristics  of  the  system  that  would  optimally  satisfy  system  objectives?"  A 
detailed  listing  of  these  characteristics  provides  the  analyst,  as  well  as  the 
decision  maker,  with  an  upper  limit  on  what  can  be  achieved.  The  ideal  may  then 
serve  as  a  kind  cf  yardstick  against  which  all  other  alternatives  may  be  evalu¬ 
ated. 

Once  the  ideal  is  obtained,  constraints  and  resources  may  be  fed  into  the 
picture  and  those  characteristics  of  the  ideal  alternative  that  are  affected  may 
oe  determined.  Constraints  and  alternatives  may  be  added  into  the  analysis  in 
various  ways,  taking  into  account  all  possible  trade-offs,  and  the  result  will 
be  a  number  of  alternative  action  plans  that  have  been  degraded  from  the  ideal 
in  various  ways  and  to  varying  extents.  For  example,  certain  categories  of 
system  performance  may  be  impacted  little,  if  at  all,  by  resource  limitations, 
or  cost  and  time  constraints.  Other  performance  categories  may,  however,  prove 
highly  sensitive  to  certain  schedules  for  resource  allocation,  time  phasing,  or 
cost  distribution.  In  any  case,  it  is  the  analyst's  responsibility  to  explore 
all  feasible  options  in  arriving  at  the  alternative  action  plans  that  he  will 
recommend  to  the  decision  maker. 

Once  the  alternatives  have  been  formulated,  tne  next  step  in  the  analysis 
is  to  evaluate  them.  Essentially,  this  amounts  to  estimating  the  effectiveness, 
cost,  and  risk  associated  with  each  alternative.  Usually,  this  step  will  have 
been  performed  in  the  process  of  generating  the  alternatives,  but  it  is  helpful 
to  conceive  of  this  activity  as  a  separate  step. 

The  effectiveness  of  a  system  amounts  to  a  judgement  about  system  perfor¬ 
mance.  It  presumes  some  yardstick  against  which  performance  may  be  evaluated. 
For  example,  if  she  reliability  of  a  training  device  is  such  that  the  average 
rate  of  failure  per  operating  period  constitutes  a  20%  downtime,  this  would 
hardly  be  viewed  as  a  reduction  in  effectiveness  if  required  utilization  time 
were  only  40%,  and  if  repairs  constituted  only  routine  adjustments  or  calibra¬ 
tion  by  operating  personnel.  Should  the  downtime  of  the  device  interfere  with 
program  scheduling,  however,  even  the  20%  figure  might  be  regarded  as  a  reduc¬ 
tion  in  system  effectiveness.  In  this  case,  the  requirement  being  impacted  is 
one  which  stipulates  student  throughput  capacity  (production).  If  required 
student  throughput  can  be  achieved  within  the  acceptable  time  frame  only  through 
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tight  temporal  coordination  of  all  system  components,  then  the  20%  downtime  of 
the  training  device  may  cause  the  productivity  of  the  system  to  drop  below 
required  levels.  Hence,  in  this  instance,  the  requirement  against  which  effec¬ 
tiveness  is  judged  is  productivity,  i.e.,  output  per  time  period.  Even  though 
no  explicit  requi remen t  may  have  existed  regarding  training  device  reliability 
in  this  example,  the  contribution  of  reliability  to  system  effectiveness  could 
be  determined  from  tne  more  general  production  requirement. 

Tne  necessity  for  the  analyst  to  indirectly  derive  criteria  for  effective¬ 
ness  evaluations  typically  arises  when  the  level  of  front-end  analysis  of  a 
system  becomes  more  detailed  than  the  initial  statement  of  the  operational 
requirement  and  includes  a  fine  breakdown  of  data  into  pertinent  categories  of 
system  performance.  As  stated  above,  these  categories  include  such  items  as 
productivity,  reliability,  maintainability,  validity,  safety,  accuracy,  accept- 
.ij-lity,  availabili ty ,  security,  and  quality.  Even  if  no  specific  requirements 
<  <.lst  for  some  of  these  categories,  if  they  represent  important  dimensions  of 
•System  performance  tie  analyst  should  develop  some  relationship  between  stated 
/stem  -'equi  rements  and  relevant  areas  of  performance,  and,  as  in  the  example 
adove,  determine  tneir  contribution  to  system  effectiveness. 

A  .econo  import  ir.t  area  for  evaluation  of  alternatives  is  cost.  The  major 
udtegcrie..  ;r.  wr-.cn  -ost  analysis  is  carried  out  are  developmental,  procurement, 
and  i ife- cycle  cost  .  Developmental  costs  include  analysis,  design,  research, 
program,  or-  orototyoi  test  and  evaluation,  and  support.  Life-cycle  costs  take 
into  account  recurr  ic;  or  continuing  costs,  nonrecurring  costs  (e.g.,  capital 
investments),  and  a-,  ureciation.  Procurement  costs  usually  consider  only  initial 
expenses  suen  as  facilities,  hardware,  implementation,  spare  parts,  support,  ana 
reprocurement . 

At  least  three  nethods  for  carrying  out  cost  analysis  are  in  current  use. 
They  are  the  parametric  method,  engineering  method,  and  analogous  system  method. 
Which  of  these  methods  tne  analyst  chooses  usually  depends  upon  how  well  the 
controlling  pa  raise  tt  r$  of  the  system  are  understood,  the  degree  of  financial 
documentation  avail... ole,  and  the  time  available  to  tne  analyst.  Since  the 
cnoice  among,  and  a.  jli cation  of,  cost  analysis  methods  is  a  complex  subject 
rseyona  tne  scoc  .  o*  tne  present  discussion,  the  reacer  is  referred  to  an  excel¬ 
lent  summary  treatr-s  nt  entitled  "Economic  Analysis  Handbook"  (Department  of 
Defense,  Defense  Eunomic  Analysis  Council,  second  edition). 

Deviously,  alternatives  cannot  be  meaningfully  compared  if  their  associated 
.  /vt ,  nave  net  been  determined  in  a  manner  that  is  both  accurate  and  consistent 
across  all  a i ternat* ves.  Furthermore,  effectiveness  of  alternatives  cannot  be 
accepted  as  a  basis  for  selecting  among  alternatives  if  it  is  not  known  what  it 
will  cost  to  achieve  the  effectiveness  promised  by  each.  If  cost  and  effective¬ 
ness  have  been  quantified  for  each  alternative  in  a  manner  that  is  standard 
across  all,  tnen  it  is  possible  to  develop  a  cost-effectiveness  index  ;or  each 
alternative.  While  this  relative  quantity  may  be  valuable  in  evaluating  alter¬ 
natives,  it  should  lie  reported  together  with  the  absolute  values  of  cost  and 
effectiveness  for  e..ch.  The  relative  values  of  two  alternatives  may  be  the 
same,  but  the  absolute  effectiveness  of  one  may  be  considerably  greater  than 
that  of  the  otner  even  though  tne  absolute  difference  in  costs  of  the  two  may  be 
insignificant.  Whatever  the  cost  analysis  technique  is  that  Che  analyst  adopts, 
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ca^e  should  be  ta<en  to  document  all  figures  and  me  assumptions  underlying  cost 
projections  and  computations.  This  is  especially  important  in  establishing  the 
appropriate  time  basis  for  comparison  of  costs  for  alternatives.  For  example, 
one  alternative  action  plan  may  require  two  years  of  developmental  costs  to 
obtain  a  five  year  benefit  period  whereas  a  second  alternative  may  require  just 
one  year  of  devel opmental  costs,  but  provide  only  three  years  of  benefit. 

The  third  major  datum  needed  for  the  evaluation  of  alternatives  is  risk. 

At  this  stage  in  the  analysis  process  risk  estimation  is  mainly  based  in  the 
subjective  judgement  of  the  analyst.  Based  on  his  knowledge  of  the  uncertain¬ 
ties  that  underlie  each  alternative,  the  tentativeness  of  the  assumptions  on 
which  the  alternative  formulations  were  founded,  the  liklihood  that  what  was 
assumed  can  in  fact  be  realized,  the  analyst  might  develop  some  sort  of  rating 
scale  by  means  or  which  his  subjective  uncertainty  could  be  assigned  a  numerical 
risk  value.  These  values  should  be  accompanied  by  an  enumeration  of  the  uncer¬ 
tainties  that  lec  to  tnem.  Risk  values  serve  to  inform  the  decision  maker  of 
tne  analyst's  beet  guess  regarding  the  probability  that  a  plan  of  action,  as 
proposed,  will  succeed,  i.e.,  the  probability  tnat  the  conditions  assumed  for  a 
given  action  plar  will  be  met.  Together,  estimates  of  effectiveness,  cost,  and 
risk  provide  a  necessary  (if  not  sufficient)  basis  for  determining  the  relative 
desirability  of  tne  various  alternative  action  plans  under  consideration.  Based 
on  these  estimates  the  alternatives  may  be  ranked  from  "best"  to  "worst". 

It  was  suggested  above  that  a  constraint-free  "ideal"  alternative  be  deter¬ 
mined.  Of  course,  the  ideal  would  be  placed  in  tne  top  position  of  the  ranking 
of  alternatives.  Although  this  ranking  merely  represents  ordinal  rel ationsni ps 
among  tne  alternatives,  some  interesting  insights  may  be  gained  by  trying  to 
estimate  the  distances  between  alternatives  on  the  ordinal  scale,  i.e.,  how  much 
better  is  eacn  alternative  as  compared  with  the  one  ranked  just  below  it?  For 
example,  d  may  be  discovered  tnat  relative  distance  between  the  ideal  and  the 
highest-ranked  realizable  alternative  is  not  appreciable.  If  such  were  the 
case,  tnis  would  indicate  that  this  realizable  alternative  is  about  as  good  ?. 
solution  to  the  :  roblem  as  could  be  achieved  even  without  any  constraints.  Of 
course,  such  a  result  may  mean  that  either  the  best  realizable  alternative  is 
rot  worth  tne  ex'enaiture  of  resources  required  to  effect  it,  or  that  the  expen¬ 
ditures  to  acv.e  e  this  alternative  can  be  expected  to  yield  highly  desirable 
results.  Simile,  reasoning  would  apply  to  alternatives  placed  at  lower  positions 
in  the  ranking. 

Another  way  of  providing  the  decision  maker  .n  estimate  of  the  distance 
between  alternat  ves  is  to  use  the  most  similar  system  already  deployed  as  a 
benchmark.  For  .xample,  when  presenting  trainin',  system  alternatives  for  a  new 
fighter  aircraft  the  analyst  could  include  the  existing  training  systems  for 
tne  current  fighter.  The  cost,  effectiveness,  arc  risks  of  the  deployed  system 
are  Known  witn  a  nign  degree  of  certainty.  Competing  the  parameters  of  each 
alternative  to  tre  Daseline  system  permits  statements  such  as  twice  as  effec¬ 
tive,  equal  in  e  ficien'iy,  etc.,  which  provide  a  setter  insertion  feed  to  a 
decision  maker  t-oroughly  familiar  with  the  existing  systems.  Ranking  also 
helps  to  iaentif  the  relative  contributions  of  the  many  factors  that  determine 
differences  in  effectiveness,  cost,  and  risk.  Fcr  example,  a  particular  alter¬ 
native  may  be  farmed  below  another  even  though  the  two  may  be  equal  in  all 
important  areas  of  performance  if  the  cost  associated  with  one  greatly  exceeds 
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that  of  the  other.  Such  cost  differences  may  reveal  fundamental  differences  in 
the  efficiency  of  one  or  more  system  components.  Perhaps  tha  hardware,  for 
example,  designated  for  two  alternatives  differs  significantly  in  development 
and  operating  costs  even  though  both  are  equally  effective.  The  alternative 
incorporating  the  mo^e  expensive  hardware  would  be  ranked  in  the  lower  position 
even  though  it  might  be  more  desirable  for  other  reasons,  e.g.,  philosophical, 
aesthetic,  political,  or  personal.  In  any  case,  the  -ankinq  of  alternatives 
provides  the  decision  maker  with  an  explicit  and  objective  summarization  of  the 
trade-offs  inherent  in  tne  alternative  action  plans  from  among  whicn  a  choice 
must  be  made. 

There  is  a  furtner  benefit  which  the  ranking  of  alternatives  provides.  Trie 
formulation  of  alternatives  inevitably  involves  assumotions  that  tne  analyst 
must  make  in  order  to  bridge  areas  of  uncertainty.  At  this  point,  the  analyst 
has  already  attempted  to  make  explicit  these  uncertainties  througn  tne  assign¬ 
ment  of  risk  values  to  each  of  the  alternatives  and  t.ney,  in  turn,  have  influ¬ 
enced  the  ranking.  As  a  means  of  further  evaluating  the  magnitude  of  influence 
of  these  uncertainties,  the  analyst  may  alter  the  assumptions  made  for  major 
parameters  of  the  system,  calculate  the  effects  of  these  changes  on  effective¬ 
ness  and  cost,  and  finally  determine  how  these  changes  are  manifest  in  the 
ranking  of  alternatives.  If  the  ranking  is  sensitive  to  changes  in  basic 
assumptions,  both  the  direction  and  magnitude  of  influence  of  uncertain  para¬ 
meters  may  be  determined.  In  case  an  area  of  uncertainty  is  associated  with  a 
high  risk  value,  the  new  ranking  of  alternatives  may  orovide  a  basis  for  select¬ 
ing  a  more  safe  plan  of  action.  Conversely,  if  the  ranking  proves  insensitive 
to  tnis  sort  of  analysis,  then  it  is  probably  safe  to  assume  that  the  uncer¬ 
tainties  encounterec  in  the  formulation  of  alternatives  will  not  invalidate  the 
relative  desirability  of  alternatives  reflected  in  the  original  ranking.  Such 
evaluations  of  the  influence  of  uncertainty  on  decision-making  have  proved 
valuable  in  economic  analysis.  Three  methods  that  are  commonly  used  are  contin¬ 
gency  analysis,  sensitivity  analysis,  and  "a  fortiori"  analysis  (see  the  Economic 
Analysis  Handbook) . 

At  some  point  ''n  the  analysis  prior  to  beginning  the  selection  process,  it 
is  the  task  of  tne  <nalyst  to  develop  selection  criteria.  These  criteria 
comprise  a  list  of  .  tatements,  preferably  quantitative,  that  delineate  in 
detail  the  maximum  acceptable  limits  permitted  by  constraints  ar.G  resources,  and 
the  minimum  acceptable  limits  afforded  by  system  objectives,  standards,  and 
specifications.  Uncer  the  heading  "Constraints  and  Resources",  the  analyst 
should  specify  such  items  as  the  maximum  acceptable  time  frames  for  completion 
for  each  phase  of  tr.e  system,  the  upper  limits  on  funding  levels  available  for 
each  phase  and  component  of  the  system,  the  facilities  and  other  physical 
resources  that  will  be  available  at  each  stage,  and  the  characteristics  of  the 
manpower,  management,  and  organizational  structure  tnat  will  be  available  during 
each  phase  of  system  emergence.  Under  the  heading  "System  Objectives,  Standards, 
and  Specifications",  the  analyst  should  include  such  items  as  the  minimal  values 
acceptable  within  each  major  area  of  system  performance  and  for  each  phase  of 
system  emergence  (analysis,  design,  development,  testing,  production,  and  imple¬ 
mentation).  Since  ahese  are  objective  statements  of  maxima  and  minima  that  have 
already  been  determined  to  be  consistent  with  operational  requirements,  overall 
funding  levels,  time  constraints,  etc.,  the  analyst  should  regard  them  as  inflex¬ 
ible  boundaries  that  define  the  region  of  acceptance  for  all  alternatives. 
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Since  t  is  like  /  that,  in  most  cases,  the  analyst  would  have  formulated  alter¬ 
natives  Ait’-  tne- e  boundaries  in  mind,  no  fully  developed  alternative  (other 
tnan  tne  ireai'  crainarily  would  be  rejected  by  the  selection  criteria.  Such 
enteric  are  val.abie  because  they  explicitly  delineate  the  arena  of  possible 
actions.  Tne  an.-.lyst  may,  however,  recommend  to  the  decision  maker  that  some 
changes  in  criteria  are  needed. 

Tne  first  step  in  the  selection  process  merely  involves  checking  each 
alternative-  ijaiiSt  the  selection  criteria.  This  step  is  illustrated  in  Figure 
3  by  tne  question  "Co  any  alternatives  meet  criteria?"  If  the  answer  to  this 
question  is  "no",  then  the  analyst  is  faced  with  either  a  reassessment  of  system 
objectives  and  performance  specifications,  or  exploration  of  new  technological 
developments  anc  management-organizational  structures.  The  information  gained 
in  tne  first  cycle  througn  the  front-end  analysis  loop  may,  indeed,  provide  a 
basis  for  a  revision  in  system  objectives  and  performance  expectations.  If  so, 
a  new  set  of  alternatives  is  generated,  evaluated,  ana  ranked.  If  not,  nerhaps 
new  tecnnologica'  developments  will  provide  more  cost-effective  approaches  to 
system  development.  Or,  perhaps,  the  utilization  of  automated  information 
candling  will  pe-mit  a  more  efficient  use  of  available  manpower  and  a  more 
streamlined  management  hierarchy.  These  possibilities,  if  feasible,  would  also 
lead  to  the  formulation  of  a  new  set  of  alternative  action  plans. 

Alternative.,  that  are  found  to  meet  the  selection  criteria  should  undergo  a 
still  further  form  of  evaluation  prior  to  final  selection.  ~hi s  stage  of  evalua¬ 
tion  ^  characterized  by  the  question  in  Figure  2  "bo  any  alternatives  merit 
selection?"  ODVOusly,  this  stage  in  the  evaluation  process  is  more  subjective 
tnan  that  involving  selection  criteria.  It  is  at  this  point  that  tne  decision 
maker  (as  well  a.,  others  such  as  system  users,  outside  experts,  etc.)  should 
become  involved  n  selection  among  those  alternatives  tr.at  satisfy  basic  cri¬ 
teria.  Given  tht.  collective  knowledge  and  past  experience  of  all  concerned, 
some  alternative,  may  be  viewed  in  a  more  desirable  light  than  others  for  a  ost 
of  reasons  that  are  largely  intuitive  and  which  may  reflect  intangible  benefits 
rot  previously  considered.  Also,  organizational  policies,  priorities,  and  long- 
ters  goals  may  *V.vor  one  alternative  over  another.  Other  factors  to  be  consid¬ 
ered  are  user  acceptance  and  the  impact  on  other  urograms  of  any  alternative 
*-  ■'  3  t  IS  $  6?  i  £  C  X,  £  .  It  is  possible  that,  at  this  point  in  the  selection  process, 
none  of  the  alternatives  may  be  judged  to  merit  selection.  Should  this  occu-, 
the  analyst  must  return  to  the  drawing  board  and  cycle  back  tnrough  the  analysis 
loop  just  as  ne  cid  when  none  of  the  alternatives  were  found  to  meet  selection 
cri teria . 

Assuming  tr-.t  one  or  more  alternative  is  foil'd  to  merit  selection,  the 
stage  of  tie  process  has  been  attained.  Selection  of  the  "best."  from 
ii-.ong  trose  alternatives  judged  to  merit  final  consideration  is,  perhaps,  the 
' east  objective  tage  of  the  process.  Not  only  is  tne  diversity  of  individuals 
-r,i  organization  •  involved  in  the  process  greater  at  this  stage,  but  the  influ- 
ev>/  o*'  non- system  forces  (international  events,  national  politics,  state  of  the 
>  . -r.  o/,  etc.)  i  •  mere  likely  to  be  manifest.  The  greater  the  magnitude  of  the 
a  .stem  under  consideration,  the  more  likely  that  these  sources  of  influence  will 
-.enact  the  decis  ons  that  are  made  during  the  final  selection  stage  of  front-enc 
analysis.  Assuming  a  "best"  alternative  is  selected,  the  ground  work  then  has 
.  een  id  ci  for  a  -V.l -scale  development  of  the  action  plan. 
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GENERIC  INFORMATION  IN  FRONT-END  ANALYSIS:  TRAINING  SYSTEMS 


In  the  introductory  section  of  this  report,  front-end  analysis  was  de¬ 
scribed  as  an  iterative  process  by  means  of  which  the  requirements  of  a  system 
may  be  made  progressively  more  definitive  and  brought  more  sharply  into  focus. 

The  importance  of  information  to  the  analysis  process  was  stressed  and  the  point 
was  made  that  the  degree  of  detail  specified  in  a  system  requirement  reflects 
the  level  of  information  that  is  available  at  the  time  of  its  formulation,  i.e., 
as  information  regarding  the  needs,  goals,  and  objectives  of  a  system  increases, 
our  view  of  what  the  system  should  accomplish  becomes  more  specific.  And,  as 
the  specificity  of  system  requirements  increases,  there  may  be  a  corresponding 
advance  in  the  state  of  the  system,  as  shown  in  Figure  4.  The  alternatives 
generated  at  each  level  of  analysis  become  more  detailed,  are  based  on  more 
information,  and  permit  a  more  definitive  description  of  system  parameters  and 
functions.  This  progressive,  step-wise,  development  of  information  and  system 
requirements  was  referred  to  as  the  straight-line  approach  to  front-end  analysis, 
as  described  in  Section  II  of  this  report, 
j 

i  Analyses,  as  they  are  carried  out  in  the  real  world  of  complex  systems  and 

j  unavoidable  constraints,  usually  must  depart  from  the  straight-line  process.  If 

|  time-cost  constraints  impose  a  less-than-optimal  approach  to  analysis,  the 

!  result  is  nearly  always  a  reduction  in  the  amount  and  quality  of  information 

J  needed  by  the  analyst  to  determine  system  requirements  and  alternative  action 

ft  plans  at  an  adequate  level  of  specificity.  Often,  the  approach  taken  by  the 

analyst  working  under  prohibitive  constraints  amounts  to  little  more  than  rule- 
x  of-thumb  or  educated  guess-work.  It  is,  thus,  of  paramount  importance  to  pro- 

f  vide  the  analyst  with  rational  strategies  that  may  be  adopted  in  the  event  that 

the  long-term  straight-line  approach  to  front-end  analysis  is  precluded  by 
constraints.  It  appears  that  the  most  likely  avenue  for  short-circuiting  the 
straight-line  process  would  be  an  information  procurement  and  management  system, 
one  that  would  maximize  the  availability  and  utility  of  information  that  is 
;  needed  at  the  time  a  system  requirement  arises.  A  generic  information  system, 

J  such  as  that  suggested  in  Section  I  of  this  report,  seems  to  offer  the  essential 

j  elements  for  developing  alternative  approaches  to  front-end  analysis.  It  is  the 

|  purpose  of  this  section  to  explore  some  of  these  approaches  within  the  context 

of  training  systems. 

As  is  the  case  for  any  system,  front-end  analysis  of  training  systems  is 
j  •  conducted  in  order  to  specify  training  requirements,  establish  instructional 

alternatives,  cost  analyze  each  alternative,  evaluate  the  effectiveness  of  each 
alternative,  anc  finally  to  select  the  most  cost-effective  plan  of  action. 
Although  tne  riger  of  the  approach  to  front-end  analysis  of  training  systems  may 
vary  depending  on  the  severity  of  the  constraints  encountered,  the  basic  steos 
of  the  analysis  process  remain  unchanged.  Essentially,  this  means  that  the 
principal  effect  of  constraints  on  front-end  analysis  is  to  reduce  tne  rigor 
with  which  it  can  be  carried  out  and  thereby  diminish  the  level  of  specificity 
at  which  instructional  regimens  can  be  delineated.  This,  in  turn,  may  degrade 
I  the  validity  of  the  alternative  that  is  selected  as  the  most  cost-effective 

solution  to  the  training  problem. 
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The  level  of  specificity  required  for  instructional  regimens  depends  upon 
the  degree  of  detail  that  is  needed  to  decide  among  alternatives.  For  example, 
if  the  problem  is  to  decide  whether  the  training  effectiveness  of  an  existing 
program  will  benefit  from  a  curriculum  revision,  the  extensiveness  of  the  analy¬ 
sis  would  be  limited  to  identification  of  any  areas  of  weakness  in  the  existing 
curriculum  and  providing  cost-effective  alternatives.  In  this  case,  the  deci¬ 
sion  to  revise  hinges  on  the  cost  of  developing  and  implementing  each  alterna¬ 
tive  curriculum  relative  to  the  gain  in  training  effectiveness  expected  for 
each.  By  contrast,  the  degree  of  detail  needed  to  generate  the  lesson  specifi¬ 
cations  and  appropriate  media  selections  for  alternative  curricula  designs  would 
be  considerably  greater.  Even  if  the  constraints  on  front-end  analysis  in  this 
situation  would  not  prohibit  an  in-depth  examination  of  curricula  alternatives, 
such  an  approach  would  be  deemed  inappropriate  since  it  would  exceed  the  level 
of  specificity  required  to  make  the  needed. decision.  The  above  example  pin¬ 
points  a  question  which  must  be  addressed  at  the  outset  of  any  front-end  analy- 
sis,  viz . ,  is  the  level  of  specificity  that  is  required  to  establish  alternative 
instructional  regimens  "greater  than",  "less  than",  or  "equal  to"  that  which  is 
achievable  given  the  existing  constraints? 

If  the  answer  to  the  above  question  is  either  "less  than",  or  "equal  to", 
tnen  the  analyst  is  free  to  select  an  approach  that  will  be  just  sufficiently 
rigorous  to  render  the  level  of  detail  necessary  to  formulate  adequately  speci¬ 
fic  training  requirements  and  instructional  regimens.  Essentially,  in  this 
case,  the  analysis  is  constraint  free.  On  the  other  hand,  if  the  answer  to  the 
above  question  is  “greater  than",  then  the  analyst  is  limited  to  an  approach 
which  will  be  less  rigorous  than  that  necessary  to  render  sufficiently  specific 
instructional  alternatives.  In  this  case,  the  analyst  must  select  an  approach 
that  will  be  achievaole  rather  than  one  tailored  to  the  nature  of  the  training 
problem.  It  is  with  this  class  of  less-than-ideal  approaches  to  front-end 
analysis  of  training  systems  thc.t  this  section  is  primarily  concerned.  The 
trade-off  between  constraints  and  achievable  specificity  of  requirements,  and 
the  ultimate  effect  of  this  trade-off  on  the  levels  of  instructional  regimens 
that  may  be  achievec,  is  illustrated  in  Figure  8.  Note  that,  if  the  achievable 
level  of  specificity  is  not  less  than  that  which  is  needed,  an  optimal  approach 
to  the  development  cf  instructional  regimens  may  be  taken.  If  such  is  not 
possible,  and  if  there  are  no  means  by  which  the  analyst  can  minimize  the  pro¬ 
hibitive  influence  of  constraints,  the  result  is  a  degraded  approach  to  analysis 
whicn  yields  a  more  grossly  specified  instructional  product.  It  is  unfortunate 
that,  often,  the  analyst  has  only  these  two  choices  available.  As  illustrated 
in  Figure  8,  the  availability  of  generic  information  may  provide  the  analyst 
with  an  approach  that  may  be  far  greater  in  its  capacity  to  specify  levels  of 
instructional  regimens.  An  analogous  possibility  also  exists  in  the  case  of  an 
approach  which  capitalizes  upon  new  media  technology. 

Before  examining  the  less-than-ideal  approaches  to  training  analysis,  it 
will  be  instructive  to  consider  the  steps  that  would  oe  taken  in  a  relatively 
constraint-free  situation,  keeping  in  mind  that  any  of  these  approaches  may  be 
distinguished  by  the  steps  that  are  taken  in  order  to  obtain  the  data  for 
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training  requirements  formulation.  For  this  purpose,  the  NAVAI R/NTEC.  ISD  model 
(Funaro  and  Mulligan,  19782;  Mulligan  and  Funaro,  19793)  will  be  regarded  as  a 
kind  of  pragmatic  ideal  the  successive  stages  of  which  may  be  used  as  a  basis 
for  comparison  with  those  of  more  constraint-laden  approaches.  The  major  phases 
and  tasks  of  this  moGel  are  diagrammed  in  Figure  9.  Only  the  initial  phase  of 
ISD  is  designated  as  analysis,  the  remaining  phases  being  design,  development, 
implementation,  and  quality  control.  However,  it  should  be  clear  that  a  straight- 
line  front-end  analysis  (which  works  on  the  outputs  cf  the  problem  analysis 
shown  as  the  first  task  in  Figure  9)  must,  at  least  conceptually,  extend  as  far 
into  the  successive  phases  of  the  ISD  process  as  necessary  in  order  to  arrive  at 
reasonable  estimates  of  training  requirements  and  time-cost  constraints.  Usually, 
training  requirements  will  have  been  determined  at  a  proper  level  of  specificity 
by  the  end  of  the  design  phase  of  ISD.  However,  estimation  of  physical  and 
manpower  resources,  time  frames,  and  cost  must  take  into  account  all  ISD  phases 
from  analysis  to  implementation  and  quality  control.  Essentially,  then,  the 
NAVAI R/NTEC  ISD  model  represents  an  optimum  alternative  for  satisfying  a  train¬ 
ing  problem.  If  time,  funds,  and  resources  permit  a  full-scale  ISD,  it  woula 
appear  that  this  would  always  be  the  analyst's  recommended  first  choice.  While 
this  is  generally  true,  in  the  area  of  training  there  is  one  important  exception. 

The  exception  is  a  generalized  training  system.  In  this  case  the  system  is 
supposed  to  prepare  students  in  the  concepts  and  tasks  that  are  prerequisites 
fo**  further  specialized  training,  where  all  of  the  specialized  programs  require 
a  common  background  of  entry-level  skills.  The  generic  nature  of  this  back¬ 
ground  is  predicated  upon  the  commonality  that  exists  among  the  different  areas 
of  specialty.  Assuming  that  each  of  the  specialized  training  programs  had  been 
developed  through  ISD,  and  that  a  commonality  analysis  such  as  that  illustrated 
in  Figure  5  had  been  carried  out  on  the  task  listings,  behavioral  objectives, 
and  training  media  (including  training  support  resources)  generated  during  each 
of  the  individual  ISDs,  this  would  constitute  a  generic  data  base  from  which  the 
training  requirements  for  the  generalized  system  could  be  determined.  Not  only 
would  no  further  ISD  be  necessary,  but  the  generalized  data  base  itself  would 
specify  the  requirements  for  the  generalized  system.  In  fact,  the  generic  data 
base  would  constitute  the  most  appropriate  picture  o~  the  training  that  would  be 
needed  to  optimally  irepare  students  for  entry  into  the  more  specialized  pro¬ 
grams.  The  generalized  requirements  obtained  from  the  generic  data  base  serve 
as  the  "best  estimat. "  of  a  system  that  will  meet  the  needs  c.£  generalized 
training.  Furthermore,  as  illustrated  in  Figure  5,  •  c r.u •  i c  data  r.sy  .  cve  a 
Dase  line  for  future  system  analyses,  especially  those  that  are  iimitec  by 
constraints. 


O 

Funaro,  J.  F.  and  Mulligan,  B.  E.  (July,  1978),  "Instructional  Systems 
Design:  The  NAVAIR/ NAVTRAEQUIPCEN  Model",  NAVTRAEQUIPCEN  Report  No.  IH-304. 

^Mulligan,  B.  E.  and  Funaro,  J.  F.  (February,  1979),  "Issues  in  the  ISD 
Process:  The  NAVAIR/ NAVTRAEQUIPCEN  Model",  NAVTRAEQUIPCEN  Report  No.  IH-309. 


26 


NAVTRAEQUIPCEN  IH 


* 


27 


IMPLEMENTATION 

PLAN 


SPECJfKA7;05 


25 


Figure  9.  NAVAIR/NTEC  ISO. 


NAVTRAEQUIPCEN  IH-325 


Since  the  relative  merits  of  the  various  generic  approaches  to  training 
analysis  that  will  be  considered  are  determined  by  the  specificity  of  require¬ 
ments  each  provides,  it  may  be  useful  to  consider  the  matter  of  specificity  in 
somewhat  concrete  terms  before  proceeding  further.  As  indicated  in  Figures  10 
and  11,  the  specificity  of  requirements  is  determined  by  the  level  of  analysis 
that  is  carried  out.  Three  categories  of  requirements  are  especially  important 
in  the  area  of  training,  viz . ,  training  program  requirements,  instructional 
media  requirements,  and  instructional  curriculum  requirements.  If  the  analysis 
is  not  carried  out  beyond  the  program  level,  requirements  can  be  stated  only  in 
the  most  general  of  terms,  containing  none  of  the  detailed  information  necessary 
for  instructional  system  development.  Specification  of  training  program  require 
ments  is  limited  to  identification  of  general  performance  areas  only,  and  media 
requirements  may  be  designated  only  in  terms  of  general  media  classes.  Curricui 
cannot  be  developed  beyond  general  instructional  content  areas,  and  the  overall 
structure  of  the  curriculum  can  be  phased  and  sequenced  only  in  terms  of  broadly 
defined  instructional  blocks.  By  contrast,  if  a  task  analysis  of  the  training 
program  has  been  completed,  the  result  is  a  marked  increase  in  the  specificity 
of  ail  requirements.  As  shown  in  Figures  10  and  11,  if  the  analysis  is  extended 
beyond  task  to  behavioral  objectives,  the  specificity  of  requirements  in  all 
categories  attains  a  level  of  detail  that  is  optimal.  It  is  this  level  of 
specificity  which  is  obtained  from  a  full-scale  ISD.  It  is  when  constraints 
will  not  permit  a  level  of  analysis  through  the  determination  of  behavioral 
objectives  that  the  availability  of  a  generic  data  base  could  contribute  signi¬ 
ficantly  to  the  determination  of  more  finely  delineated  requirements  than  would 
otherwise  be  achievable.  For  example,  if  the  operational  requirement  calls  for 
the  development  of  a  training  device,  and  if  the  analyst  has  available  to  him 
only  data  at  the  task  level,  he  may  specify  requirements  for  types  of  displays 
and  manipulanda,  etc.,  for  the  device,  but  he  will  not  have  sufficient  informa¬ 
tion  to  stipulate  with  any  degree  of  accuracy  such  characteristics  of  the  device 
as  fidelity  of  simulation  of  display,  response,  and  environmental  dimensions 
(modality,  dynamic-static,  color,  etc.;  manipulanda  characteristics,  response 
feedback,  motion  cues,  etc.).  However,  if  the  system  under  consideration  were 
one  of  a  number  of  similar  systems  with  common  characteristics,  generic  infor¬ 
mation  derived  from  previous  analyses  of  these  systems  could  be  used  to  enhance 
the  level  of  detail  at  which  the  requirements  for  the  device  under  consideration 
could  be  specified.  In  this  case,  the  augmentation  of  task  level  requirements 
with  generic  requirements  would  not  yield  a  level  of  specificity  equivalent  to 
that  obtainable  through  a  full-scale  ISD,  but  it  would  yield  a  level  of  specifi¬ 
cation  greater  than  that  achievable  on  the  basis  of  task  level  information 
alone. 

In  the  area  of  training  the  alternative  action  plans  to  be  determined  by 
the  analyst  are  instructional  regimens,  i.e.,  descriptions  of  training  programs 
including  task,  behavioral,  media,  and  curricula  requirements  (as  well  as  sup¬ 
port,  time,  funding,  etc.  requirements).  It  is,  therefore,  meaningful  to  com¬ 
pare  the  various  aporoaches  to  training  analysis  on  a  continuum  of  specificity 
of  instructional  regimens  that  may  be  achieved  by  each  approach.  As  pointed  out 
earlier,  the  various  approaches  to  training  analysis  may  be  distinguished  on  the 
basis  of  the  steps  that  constitute  each.  Insofar  as  front-end  analysis  of 
training  is  concerned,  however,  the  various  approaches  may  be  adequately  distin¬ 
guished  in  terms  of  three  stages  -  the  program  level,  the  task  analysis  level, 
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Figure  11.  Specificity  of  Requirements:  Curriculum. 
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and  the  behavioral  analysis  level.  This  is  illustrated  in  Figure  12  for  three 
nongeneric  approaches  to  training  analysis.  There  it  can  be  seen  tnat  if  con¬ 
straints  permit  task  analysis  and  behavioral  analysis,  the  analyst  may  complete 
the  remaining  frcnt-end  steps  in  the  ISO  model  ana  define  alternative  instruc¬ 
tional  regimens  at  a  high  level  of  specificity.  3y  contrast,  if  constraints 
will  not  permit  task  analysis,  training  requi remer.ts  must  be  estimated  from 
statements  of  program  goals,  objectives,  etc.,  and  the  analyst  is  limited  to 
determinations  or  general  classes  of  media  and  instructional  content  areas. 
Consequently,  tnt  alternative  instructional  regimens  that  can  be  formulated  on 
the  basis  of  such  limited  information  are  necessarily  of  gross  specificity.  As 
the  information  available  to  the  analyst  increases,  so  too  does  the  specificity 
of  the  training,  media,  and  curricula  requirements.  As  shown  in  Figure  12,  f 
constraints  will  permit  just  a  task  analysis,  an  intermediate  level  of  specifi¬ 
city  may  be  achieved  for  instructional  regimens.  In  these  three  instances  no 
generic  information  is  assumed  to  be  available  to  the  analyst,  a  condition  that 
typifies  most  training  analyses. 

» 

It  should  be  clear  that  the  likely  validity  of  any  instructional  regimen, 
or  plan,  will  be  greatest  if  the  information  is  available  to  permit  a  high 
degree  of  specificity  in  it*^  formulation.  Tne  question  of  importance  at  this 
point  is  what  magnitude  of  gain  in  specificity  of  instructional  regimens  can  be 
expected  if  various  degrees  of  generic  information  can  be  incorporated  into  the 
training  analysis?  Consider  first  the  gain  that  it, ay  be  obtained  by  the  inclu¬ 
sion  of  a  generic  task  listing  in  the  analysis  process,  as  illustrated  in  Figure 
13. 


The  tornado-like  funnel  in  the  upper  right  hand  corner  of  Figure  13  is 
meant  to  symbolize  the  collection  of  a  number  of  task  listings  drawn  from 
systems  whose  key  parameters  have  sufficient  commonality  to  permit  the  deriva¬ 
tion  of  a  generic  task  list,  or  data  base  (a  suggestion  of  how  such  a  data  base 
might  De  organized  is  presented  in  Figure  5).  For  purposes  of  comparison,  two 
nongeneric  approaches  are  included  on  the  diagram  in  Figure  13.  They  are  shown 
on  the  left  side  of  the  diagram  for  the  case  where  a  "yes"  answer  is  given  to 
the  question,  will  constraints  permit  full  task  analysis?  The  left -most  verti¬ 
cally  descending  sequence  of  steps  is,  as  in  Figure  12,  a  full-scale  ISD  analy¬ 
sis.  Tne  approach  that  results  if  a  "no"  an'wer  is  given  to  the  question,  will 
constraints  perrrrt  behavioral  analysis?,  is  Imited  solely  to  a  task  listing 
from  which  train’ng  and  other  requirements  must  be  determined  and  instructional 
regimens  formulated.  As  the  diagram  indicates,  the  level  of  specificity  that 
can  be  achieved  in  the  latter  case  is  significantly  reduced  from  that  attainable 
with  a  full  ISD. 

The  gain  in  number  of  approaches  to  analysis  due  to  the  availability  of 
the  generic  task  data  base  occurs  on  the  "no"  sioe  of  the  initial  question,  will 
constraints  perm- t  full  task  analysis?  As  was  shown  in  Figure  12,  the  lack  of  a 
generic  task  data  base  at  this  point  limits  the  analysis  to  the  program  level 
which  results  in  a  very  gross  degree  of  speci fi cation  of  instructional  regimens. 
Hence,  the  advantage  of  having  a  generic  task  data  base  is  realized  when  con¬ 
straints  will  not  permit  full  task  analysis.  As  the  diagram  in  Figure  13  indi¬ 
cates,  however,  there  is  one  approach  which  results  from  the  availability  of  a 
generic  task  data  base  that  is  superior  even  to  that  obtained  when  constraints 
do  permit  a  full  task  analysis. 
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The  way  in  whicn  this  superior  approach  is  achieved  may  be  explained  by 
stepping  througn  the  appropriate  path  in  Figure  13  with  an  example  in  mind. 

Assume  that  time  and/or  cost  constraints  will  not  permit  a  full  task  analysis, 
but  that  the  system  *or  which  a  training  program  is  needed  is  well  understood  in 
the  sense  that  its  primary  functions  are  explicitly  delineated.  In  other  words, 
the  engineering  data  available  to  the  analyst  stipulates  what  the  system  does 
under  each  condition  in  which  it  is  to  be  used.  Furthermore,  assume  that  this 
particular  system  is  one  of  a  class  of  such  systems  for  which  task  analyses  have 
Deen  carried  out,  and  that  the  task  listings  of  these  generically  related  systems 
have  been  subjected  to  a  commonality  analysis  thus  forming  a  generic  task  data 
base.  Now  then,  if  the  constraints  to  which  the  analyst  is  subject  will  permit 
an  identification  of  system-specific  functions,  he  may  determine  from  these  a 
list  of  tasks.  As  indicated  in  the  diagram,  these  system-specific  tasks  may 
then  De  summed  with  the  generic  tasks  which  will  yield  a  fairly  rigorous  and 
representati ve  task  listing.  If,  at  this  point,  constraints  will  not  permit  any 
further  analysis,  the  result  will  be  a  level  of  specificity  for  instructional 
regimens  that  is  a  little  less  fine  than  that  which  would  have  been  ODtained  if 
a  full  task  analysis  had  been  performed.  But,  if  constraints  should  allow  the 
analyst  to  proceed  further  with  behavioral  and  media  analyses,  i.e.,  essentially 
completing  the  remaining  steps  in  the  ISO  model,  then  a  level  o+'  specificity  may 
be  achieved  which  is  only  a  little  less  fine  than  that  achievable  by  a  full- 
scale  ISD. 

In  the  above  example,  the  analyst  determined  system-specific  tasks  from 
known  system  functions,  combined  these  with  generic  tasks,  performed  behavioral 
and  media  analyses  on  the  integrated  task  list,  determined  program,  media, 
curricula,  and  other  requirements  from  these  analyses,  and  finally  formulated 
alternative  instructional  plans  to  meet  these  requirements.  This  entire  front- 
end  analysis  was  carried  out  on  available  documentation,  i.e.,  descriptions  ot 
system-specific  functions  and  a  generic  task  listing.  In  order  to  achieve  a 
relatively  high  level  of  specificity,  it  was  not  necessary  for  the  analyst  to 
undertake  a  full  task  analysis.  While  this  approach  would  be  appropriate  for 
either  existing  or  emerging  systems,  it  would  seem  to  be  especially  advantageous 
for  the  latter  since,  in  the  early  stages  of  an  emerging  system,  all  that  the 
analyst  would  nave  available  to  him  would  be  descriptions  of  system  functions. 

There  is  one  further  gain  in  specificity  of  instructional  regimens  that 
may  be  obtained  by  basing  a  front-end  analysis  on  a  generic  task  data  base.  If 
constraints  permit  neither  a  full  task  analysis  nor  identification  of  system- 
specific  functions,  the  level  of  specificity  that  can  be  achieved  by  means  of  a 
generic  task  data  base  is  significantly  greater  than  that  which  would  be  achieved 
on  the  basis  of  requirements  determined  from  training  goals,  program  objectives, 
etc.,  which  were  shown  to  be  the  worst  of  the  nongeneric  approaches  in  Figure  12. 
The  analysis  based  on  generic  tasks  alone  is  illustrated  in  Figure  13  by  the 
dashed  line. 

In  summary,  the  availability  of  a  generic  task  oata  base  has  been  shown  to 
provide  the  analyst  with  three  additional  approaches,  each  of  which  is  superior 
to  the  only  nongeneric  approach  that  would  otherwise  be  available  to  the  analyst 
if  constraints  do  not  permit  a  task  analysis.  This  fact  alone  would  seem  to 
constitute  sufficient  justification  for  the  generic  approach  to  analysis. 

However,  there  are  further  gains  to  be  realized  from  the  utilization  of  generic 
information. 
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Since  the  reader  is  now  familiar  with  the  conceptual  structures  represented 
in  the  diagrams  being  considered,  it  is  unnecessary  to  discuss  the  remaining 
models  in  detail.  It  will  be  left  for  the  reader  to  trace  out  the  steps  involved 
in  the  various  paths  diagrammed  in  Figures  14  ano  15.  By  doing  so,  the  reader 
will  discover  a  number  of  interesting  applications  of  generic  information  to 
front-end  analysis.  Several  features  of  these  generic  models,  however,  should 
be  noted. 

The  model  diagrammed  in  Figure  14  assumes  the  existence  of  both  a  gener'c 
task  data  base  and  a  generic  behavioral  objectives  data  base.  As  in  the  previous 
generic  task  model,  generic  tasks  are  determined  by  performing  a  commonality 
analysis  on  a  number  of  task  listings  from  similar  systems.  Behavioral  objec¬ 
tives  determined  from  these  generic  tasks  are,  themselves,  generic  in  character 
and  thus  form  a  more  advanced  stage  in  the  development  of  generic  information. 

It  may  be  seen  in  Figure  14  that  the  availability  of  a  generic  data  base  at  the 
level  of  behavioral  objectives  yields  three  additional  approaches  to  training 
analysis,  two  of  which  achieve  relatively  high  orders  of  specificity.  The 
third,  which  is  the  worst  case,  may  be  seen  to  achieve  a  somewhat  higher  level 
of  specificity  tnan  the  worst  approach  possible  with  the  generic  task  model. 

The  model  diagrammed  in  Figure  15  assumes  that  the  development  of  generic 
information  has  progressed  ail  the  way  to  a  generic  media  data  base.  Again, 
three  additional  approaches  to  training  analysis  also  result  from  this  model, 
and  each  achieves  a  high  level  of  specificity.  Two  nongeneric  approaches  are 
represented  in  this  model,  as  well  as  one  approach  involving  only  generic 
tasks.  It  should  be  apparent  to  the  reader  that,  even  though  these  models  were 
constructed  on  the  premise  that  constraints  comprise  the  primary  limitations 
encountered  by  the  analyst,  one  approach  may  be  more  suitable  than  another  for 
analysis  of  a  training  problem  depending  on  the  nature  of  the  problem  itself. 

Overall,  by  incorporating  generic  information  into  the  training  analysis 
process  through  the  models  developed  here,  twelve  different  approaches  to 
analysis  may  be  realized.  As  compared  with  the  three  approaches  based  on 
nongeneric  information,  this  represents  a  considerable  increase  in  the  avenues 
and  outcomes  that  can  be  attained  through  use  of  generic  information.  The 
twelve  approaches  are  listed  in  Figure  16.  Each  approach  is  designated  by  the 
informational  components  and  steps  contained  in  the  analysis.  They  are  rank 
ordered  from  one  to  twelve  according  to  the  specificity  that  may  be  obtained  by 
each.  It  can  be  seen  that  an  analysis  consisting  of  all  ISD  front-end  steps 
results  in  the  greatest  specificity  of  instructional  regimens,  and  that  an 
analysis  based  solely  on  program  goals  results  in  the  lowest  degree  of  specifi¬ 
city. 


One  further  approach  to  training  analysis  nas  been  distinguished,  one 
involving  the  simultaneous  development  of  new  training  technology  and  front-end 
training  analysis.  This  approach  is  illustrated  in  Figure  17.  Ordinarily,  the 
selection  of  training  media  is  not  done  until  after  training  requirements  have 
been  determined.  It  is  not  unusual,  however,  for  the  analyst  to  be  faced  with 
constraints  that  make  it  impossible  to  satisfy  training  goals  with  existing 
media  technology.  For  example,  if  training  goals  require  the  development  of  a 
simulator  the  cost  of  which  exceeds  by  a  wide  margin  the  level  of  funding  avail¬ 
able,  the  analyst  may  be  faced  with  a  double  problem,  i.e.,  one  involving  both 
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Figure  15.  Levels  of  Specificity  From  Approaches  Based  on  Complete 
Generic  Data  Base. 
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NOTE:  IF  VALIDITY  IS  DEGRADED  BY  CONSTRAINTS  ON  EXISTING  MEDIA, 

NEW  TECHNOLOGY  DEVELOPMENT  MAY  BE  USED  TO  RECOVER  THE  LOSS 

Figure  16.  Components  of  Training  Analyses  Ranked  According  to  Levels  of  Specificity  Achieved. 
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time  and  cost.  Obviously,  the  analyst  must  explore  alternative  possibilities 
for  obtaining  a  device  with  the  required  simulation  capabilities  at  a  lower  cost 
than  that  inherent  in  the  use  of  current  technology.  This  may  take  considerable 
time,  especially  if  the  new  media  technology  development  has  to  wait  until  after 
completion  of  the  various  steps  in  the  training  analysis.  It  is  this  situation 
for  which  the  model  represented  in  Figure  17  was  designed. 

By  developing  the  training  requirements  and  new  media  technology  in  parallel, 
it  may  be  possible  to  overcome  both  the  time  and  cost  constraints.  As  the  model 
indicates,  after  completion  of  the  first  step  in  the  training  analysis,  i.e., 
development  of  training  program  objectives,  a  gross  specification  of  media 
requirements  may  be  used  as  the  basis  for  a  feasibility  study  aimed  at  delineat¬ 
ing  the  concept  of  simulation  by  new  technology.  Thus,  as  task  analysis  is 
being  carried  out,  the  feasibility  study  has  also  been  gotten  under  way.  Upon 
completion  of  task  analysis,  the  specifications  of  media  requirements  may  be 
further  refined  and  these  used  at  the  end  of  the  feasibility  study  for  prelimi¬ 
nary  development  of  media  alternatives.  As  the  latter  is  progressing,  the 
development  of  behavioral  objectives  is  also  being  carried  out.  Completion  of 
the  latter  enables  formulation  of  the  final  media  specifications  which  will  then 
be  available  for  design  of  the  new  media.  By  the  time  the  new  media  descrip¬ 
tions  are  available,  the  training  requirements  will  have  been  formulated  and  the 
process  of  media  selection  may  be  initiated.  The  new  training  technology  devel¬ 
opment  is,  thus,  driven  by  progressive  refinements  of  media  specifications  at 
each  stage  of  the  training  analysis.  It  is  this  exchange  and  updating  of  infor¬ 
mation  between  the  engineers  and  the  training  analyst  which  makes  it  possible  to 
carry  out  the  new  technology  development  within  the  same  time  frame  as  the 
training  analysis.  Although  the  model  presented  in  Figure  17  assumes  complete 
ISO  steps  for  analysis,  it  is  entirely  possible  that  any  of  the  generic  models 
described  previously  could  be  substituted  in  place  of  the  ISD  approach. 
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